feat: Support EKS Auto Mode custom node pools only creation #3514
Conversation
bryantbiggs
force-pushed
the
feat/custom-node-pools
branch
from
13a9ea7 to
5db485e
Compare
| content { | ||
| dynamic "elastic_load_balancing" { | ||
| for_each = local.auto_mode_enabled ? [1] : [] | ||
| for_each = [var.compute_config] |
There was a problem hiding this comment.
This approach works also! Just an alternative way to do the same thing I was doing in #3513. :)
There was a problem hiding this comment.
Actually, I think you'll run into an error when var.compute_config == null, which is the default value for the variable. The construct that I used handles that scenario, var.compute_config[*].
There was a problem hiding this comment.
Oh I see, that's why you had to change the default to {} and make it un-nullable. Of course that means the blocks will always be present now, even when not using auto mode.
| enable_encryption_config = var.encryption_config != null && !local.create_outposts_local_cluster | ||
|
|
||
| auto_mode_enabled = try(var.compute_config.enabled, false) | ||
| create_auto_mode_iam_resources = var.compute_config.enabled || var.create_auto_mode_iam_resources |
There was a problem hiding this comment.
I can appreciate the logic behind having a separate var to create the auto mode iam resources. If that's the interface you wish to expose, then certainly makes sense.
## [21.3.0](v21.2.0...v21.3.0) (2025-09-16) ### Features * Support EKS Auto Mode custom node pools only creation ([#3514](#3514)) ([165d7c8](165d7c8))
|
This PR is included in version 21.3.0 🎉 |
| # Create just the IAM resources for EKS Auto Mode for use with custom node pools | ||
| create_auto_mode_iam_resources = true |
There was a problem hiding this comment.
This isn't quite enough. It is still necessary to enable auto mode, in order to use custom node pools with auto mode...
compute_config = {
enabled = true
node_pools = []
}
|
The title here is not actually accurate. It was already possible to create a cluster with auto mode enabled, and configured to use only custom node pools. I've been doing it for months with this module. The enhancement I was working on in #3513 was to allow a user to switch between the built-in node pool configuration and custom node pool configuration, without error and without recreating the cluster. |
|
My existing cluster is unable to use this new version: # module.some_module.some_eks_cluster.this[0] will be updated in-place
~ resource "aws_eks_cluster" "this" {
id = "some-eks-cluster"
name = "some-eks-cluster"
# (14 unchanged attributes hidden)
+ compute_config {
+ enabled = false
}
+ storage_config {
+ block_storage {
+ enabled = false
}
}
# (5 unchanged blocks hidden)
}
eks cluster definitionmodule "eks" {
source = "terraform-aws-modules/eks/aws"
name = var.vpc_module.eks.control_plane.cluster_name
kubernetes_version = var.kubernetes_version
enable_cluster_creator_admin_permissions = true
endpoint_public_access = true
endpoint_public_access_cidrs = var.endpoint_public_access_cidrs
addons = {
coredns = {}
eks-pod-identity-agent = {
before_compute = true
}
kube-proxy = {}
vpc-cni = {
before_compute = true
}
}
vpc_id = var.vpc_module.vpc.vpc_id
subnet_ids = var.vpc_module.vpc.private_subnets
control_plane_subnet_ids = var.vpc_module.vpc.intra_subnets
eks_managed_node_groups = {
karpenter = {
ami_type = var.karpenter.ami_type
instance_types = var.karpenter.instance_types
min_size = var.karpenter.min_size
max_size = var.karpenter.max_size
desired_size = var.karpenter.desired_size
labels = {
"karpenter.sh/controller" = "true"
}
}
}
access_entries = var.access_entries
} |
|
@ayuris-liveramp Ahh. That's because the blocks are always present now... The approach in #3513 would have avoided that problem. |
No, no it would not. Any solution is susceptible to failure. Collecting details to share with the EKS service team. For now, pin your module version to |
Yes, it actually did. I tested it. It worked because the logic on the dynamic blocks removed them from the config when The only possible way to run into this error with that approach would be to create a cluster with auto mode enabled, then disable it by setting But the upgrade path for any existing cluster was just fine. |
|
I also had to pin as this upgrade broke our cluster with a half-completed terraform apply with the same error about |
|
Running into same issue. This is on US Gov cloud where EKS Auto Mode is not supported at all. |
|
AWS provider version v6.15.0 should be released tomorrow with the fix - we'll bump the MSV for the AWS provider here and release a new patch version which should resolve this issue |
Description
compute_config.node_role_arnwhen disabling auto mode or built-in node pools hashicorp/terraform-provider-aws#42483compute_configdefault value changed to{}to use variable optional attribute defaults and setnullable = false. The API seems to now support creating clusters withcompute_config.enabled = false/storage_config.block_storage.enabled = false/kubernetes_network_config.elastic_load_balancing.enabled = falsewhich was not supported at launch for Auto Mode. This simplifies the configuration to where its eithertrueorfalse; changing the default and disablingnullsimplifies the value checking (lessthing != nullor catching errors with atry()because it could be null)Motivation and Context
Breaking Changes
How Has This Been Tested?
examples/*to demonstrate and validate my change(s)examples/*projectspre-commit run -aon my pull request